LAN-based UMA network controller with aggregated transport

ABSTRACT

A method for managing UMA communications within a local area network and a network controller includes establishing a first connection between a first UMA device and a LAN-based UMA network controller (LAN-UNC) and establishing a second connection between a second UMA device and the LAN-UNC. The first and second connections are carried over the local area network. The first and second UMA devices are connected to the same local area network. The method provides establishing a third connection between the LAN-UNC and a UMA network controller (UNC). The UNC is connected to an external network and the third connection extends over the external network. The method includes transporting packets received using the first and second connections to the UNC using the third connection. Packets received using the third connection are transported to the first UMA device using the first connection and to the second UMA device using the second connection.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/432,305, filed May 10, 2006, which claims priority to U.S.Provisional Application No. 60/594,827, filed May 10, 2005, all of whichare incorporated herein by reference in their entirety.

The following two applications are also incorporated herein by referencein their entirety:

-   -   U.S. patent application Ser. No. 11/432,280, filed May 10, 2006        by Troy T. Pummill, Kevin Isacks, Terry Hardie, and Talbot        Harty, for “LAN-BASED UMA NETWORK CONTROLLER WITH LOCAL SERVICES        SUPPORT”; and    -   U.S. patent application Ser. No. 11/432,302, filed May 10, 2006        by Troy T. Pummill, Kevin Isacks, Terry Hardie, and Talbot        Harty, for “LAN-BASED UMA NETWORK CONTROLLER WITH PROXY        CONNECTION”.

BACKGROUND OF THE INVENTION

Unlicensed mobile access (UMA) technology provides a link betweenGSM/GPRS cellular networks and IP-based wireless access networks. Thislink enables a cellular provider to offer the same voice and dataservices regardless of whether the services are delivered by a cellularbase station or an IP network. Built-in handover mechanisms and mobilitymanagement features make it possible to transition between the twoaccess methods without interrupting service.

In a typical implementation, a UMA network controller (UNC) passes voiceand data signals between a mobile station and the core cellular network.The UNC receives UMA packets from the mobile station over an IP network,converts them into a suitable format, and directs them to the corecellular network. The core cellular network receives voice traffic at astandard A-interface and data traffic at a standard Gb-interface. In theother direction, the cellular core signals the UNC at its interfaces,the UNC converts these signals into packets, and the UNC sends thepackets to the mobile station over the IP network. The entire process istransparent to both the mobile station and the cellular core. From themobile station's perspective, the wireless network is simply anadditional radio resource. IP-specific functionality is abstracted fromthe higher level service and control logic. The core cellular network,on the other hand, interacts with the UNC as if it was a conventionalbase station. At a high level, the UMA network functions as a singlecell within the larger cellular network.

The UNC participates in a process of authentication whereby the mobilestation is granted access to the core cellular network. As a part ofthis process, the mobile station contacts the UNC at an address on theIP network. The UNC contacted may or may not be the UNC that serves thegeographic area in which the mobile station is located. A mobile stationmay contact multiple UNCs before locating the serving UNC and becomingregistered as part of the UMA network. A security gateway at the servingUNC employs a challenge-response mechanism to authenticate the mobilestation. As part of this process, the mobile station exchanges encryptedcommunications with the core cellular network. The encryptedcommunications contain information derived from a subscriber identitymodule (SIM) located within the mobile station. When authentication issuccessfully completed, the serving UNC provides system information tothe mobile station so that its availability at the UMA network cell canbe registered with the core cellular network.

After registration is complete, signaling and bearer traffic flowbetween the mobile station and the serving UNC through an IPsec (IPSecurity) tunnel When the mobile station wishes to place a call, forexample, it sends UMA packets to the serving UNC requesting aconnection. The serving UNC notifies a mobile switching center (MSC) inthe core cellular network. The MSC then directs the serving UNC tocreate a voice path from the mobile station to a voice port on itsA-interface. The serving UNC responds by creating a Voice over IP (VoIP)bearer path to the mobile station. Audio is transported back and forthacross the IP network as a VoIP data flow on the bearer path. When theserving UNC receives audio data from the mobile station, it istranscoded and directed to a voice port at the A-interface. Similarly,when the serving UNC receives audio data from the MSC, it is transcodedand sent to the mobile station over the bearer path. All communicationsare passed through the IPsec tunnel for security.

GPRS data services are also available on the UMA network. When a mobilestation wishes to access these services, it creates a transport channelto the serving UNC. The transport channel carries GPRS payload packetsbetween the mobile station and the serving UNC. The serving UNC forwardspayload packets received from the mobile station to a serving GPRSsupport node (SGSN) through its Gb interface. In like manner, theserving UNC receives GPRS packets from the SGSN and forwards them to themobile station over the transport channel.

FIG. 1 illustrates the operation of a conventional UMA communicationsystem. UMA communication system 100 is shown as including, in part,mobile stations 108, 110 and local area network (LAN) 104. LAN 104includes workstations 116, 117 and application server 118. An internetconnection 120 is also provided. Mobile stations 108, 110 connect to LAN104 through a wireless access point 112.

When mobile station 108 wishes to place a UMA call, for example, itconnects to LAN 104 and begins a process of authentication with the corecellular network through a serving UNC 124. This process results information of a secure tunnel between the devices. At this point, mobilestation 108 communicates with serving UNC 124 by sending and receivingUMA packets through the secure tunnel. These packets represent GSM/GPRSsignaling and bearer traffic. Depending upon the type of communication,serving UNC 124 relays packet data either to MSC 128 or SGSN 132 whereit is presented to the core cellular network. Return communicationsfollow the same path from the core cellular network to the mobilestation.

As shown and described, conventional UMA communication system 100neglects the resources and functionality of local area network 104.Regardless of caller/callee, all voice communications follow a path fromsender, across the internet, to the UNC, and back down to the recipient.This is true even if both devices are connected to the same local areanetwork. Thus, if mobile station 108 wishes to call mobile station 110,audio data from mobile station 108 will be transmitted to the local areanetwork 104, traverse the internet 120, and be received at serving UNC124. Serving UNC 124 will return the audio data over the internet 120 tothe local area network 104 where it will ultimately be received bymobile station 110. This process uses network bandwidth inefficiently,introduces delay into UMA voice calls, and potentially degrades callquality.

In addition, by neglecting LAN resources, UMA devices in a conventionalsystem are not able to communicate efficiently with other LAN-basedcommunication devices. For example, a LAN may support interoperabilityamong numerous SIP, H.323, and TDM based communication devices throughone or more media gateways. UMA devices do not benefit from this sharedconnection. As described, UMA communications always traverse theinternet before reaching their intended recipients. Thus, there is aneed in the art for a LAN-centric approach to UMA communications. It istherefore an object of the present invention to promote efficient voiceand data communications for UMA-enabled devices connected to the samelocal area network. It is also an object of the present invention topromote efficient communication between UMA and non-UMA communicationdevices when these devices are connected to the same local area network.

BRIEF SUMMARY OF THE INVENTION

A method for managing UMA communications within a local area network anda network controller are disclosed. The method includes establishing afirst connection between a first UMA device and a LAN-based UMA networkcontroller (LAN-UNC) and establishing a second connection between asecond UMA device and the LAN-UNC. The first and second connections arecarried over the local area network. The first and second UMA devicesare connected to the same local area network. The method providesestablishing a third connection between the LAN-UNC and a UMA networkcontroller (UNC). The UNC is connected to an external network and thethird connection extends over the external network. The method includestransporting packets received using the first and second connections tothe UNC using the third connection. Packets received using the thirdconnection are transported to the first UMA device using the firstconnection and to the second UMA device using the second connection.

According to another embodiment, the third connection comprises an IPsectunnel. The IPsec tunnel formation process may be performed manually orautomatically. In one embodiment, the LAN-UNC detects a USB-SIM deviceand initiates an automated IPsec tunnel formation process. The thirdconnection may transport authentication packets between the first UMAdevice and the UNC. Authentication packets may be exchanged as part of aprocess whereby the first UMA device is authorized to access a cellularnetwork. In some embodiments, LAN-UNC monitors the authenticationprocess and detects when it has been successfully completed. The firstUMA device may provide cellular triplets to LAN-UNC to facilitatemonitoring the authentication process. Alternatively, the UNC mayprovide the cellular triplets.

In one embodiment, the method includes forming a multiplexed packet withdata from packets received on the first and second connections andsending the multiplexed packet to the UNC on the third connection. Inadditional embodiments, the packets transported using the thirdconnection are compressed and otherwise optimized.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a UMA communication system as known in the priorart.

FIG. 2 depicts a LAN-based UMA network controller (LAN-UNC) operating aspart of a UMA communication system in accordance with an embodiment ofthe present invention.

FIG. 3 shows an exemplary device location table maintained by aLAN-based UMA network controller according to an embodiment of thepresent invention.

FIG. 4 is a conceptual view of a LAN-UNC disposed within a securecommunication channel.

FIG. 5 shows parts of an authentication process conducted according toan embodiment of the present invention.

FIG. 6 shows parts of an authentication process conducted according toanother embodiment of the present invention.

FIG. 7 shows exchanges forming part of an authentication processconducted according to a further embodiment of the present invention.

FIG. 8 is a simplified block diagram of a LAN-UNC interacting withelements of a UMA communication system according to an embodiment of thepresent invention.

FIG. 9 shows parts of an authentication process conducted according toan embodiment of the present invention.

FIG. 10 shows exchanges forming part of an authentication processaccording to an embodiment of the present invention.

FIG. 11 shows parts of an authentication process conducted in accordancewith an embodiment of the present invention.

FIG. 12 is a simplified block diagram of a LAN-UNC operating as part ofUMA communication system according to an embodiment of the presentinvention.

FIG. 13 is a simplified block diagram of a LAN-UNC interacting withelements of a UMA communication system according to an embodiment of thepresent invention.

FIG. 14 shows portions of an authentication process conducted accordingto one embodiment of the present invention.

FIG. 15 is a simplified block diagram of a LAN-UNC operating as part ofa UMA communication system according to an embodiment of the presentinvention.

FIG. 16 shows exchanges forming part of an authentication processconducted according to an embodiment of the present invention.

FIG. 17 shows parts of an authentication process conducted in accordancewith another embodiment of the present invention.

FIGS. 18A and 18B show parts of a discovery process for a mobile stationthat has not previously accessed UMA service according to an embodimentof the present invention.

FIGS. 19A and 19B illustrate portions of a discovery process for amobile station that has recorded information about a default UMA networkcontroller according to an embodiment of the present invention.

FIGS. 20A and 20B illustrate parts of a discovery process for a mobilestation MS provisioned with the full-qualified domain name of a LAN-UNCin accordance with an embodiment of the present invention.

FIGS. 21A and 21B illustrate aspects of a discovery process according toa further embodiment of the present invention.

FIGS. 22A and 22B show an embodiment of the present invention in which aLAN-UNC interacts with UMA devices that are not connected to the localarea network.

FIGS. 23A and 23B show parts of a registration process conducted inaccordance with an embodiment of the present invention.

FIGS. 24A and 24B show portions of a registration process conductedaccording to a further embodiment of the present invention.

FIG. 25 shows a LAN-UNC operating as part of a UMA communication systemin accordance with an embodiment of the present invention.

FIGS. 26A and 26B show LAN-UNCs according to additional embodiments ofthe present invention.

FIG. 27 is a flow chart showing steps performed to localize call audiodata according to an embodiment of the present invention.

FIG. 28 is a flow chart showing steps performed as part of a handoverprocess according to an embodiment of the present invention.

FIG. 29 is a flow chart showing a local call completion processaccording to an embodiment of the present invention.

FIG. 30 is a flow chart showing steps performed as part of a discoveryand registration process according to one embodiment of the presentinvention.

FIG. 31 is a simplified block diagram a LAN-UNC according to anembodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 2 shows a LAN-based UMA network controller 236 (LAN-UNC) operatingas part of a UMA communication system according to an embodiment of thepresent invention. In this arrangement, local area network 204 mayrepresent an enterprise network and may support various computing andcommunication devices. As shown, local area network 204 includesworkstation 216 and application server 218. Application server 218provides data services to devices that are connected to LAN 204. Devicesconnected to LAN 204 may communicate over an external network 220 byexchanging IP (Internet Protocol) packets.

UMA devices 208, 210, 240 are also part of local area network 204.Mobile stations 208, 210 connect to LAN 204 through wireless accesspoint 212. Access point 212 provides a means for wireless devices in itscoverage area to connect to LAN 204 and may perform other routing andsecurity related functions. Access point 212 may accept connections fromWiFi, WiMax, Bluetooth, and other wireless-enabled devices. UMA phone240 is a fixed-line device that includes an integrated UMA client andcommunicates over a UMA network (UMAN) in the same way as conventionalUMA devices. In some embodiments, UMA phone 240 is an Ethernet device.

LAN-UNC 236 is also connected to local area network 204 and disposed toreceive packets from UMA devices 208, 210, 240. Packets sent by UMAdevices 208, 210, 240 pass through LAN-UNC 204 before they reachexternal network 220. Similarly, packets arriving from external network220 are received by LAN-UNC 236 before they reach UMA devices 208, 210,240.

I. Local Communications

A. Call Audio

In an exemplary embodiment, LAN-UNC 236 monitors packets exchanged byUMA devices 208, 210, 240. If it detects that packets received from aUMA device 208, 210, 240 represent a call, LAN-UNC 236 may examine thepackets to determine whether the called party is connected to local areanetwork 204. For example, mobile station 208 may request a call usingstandard UMA connection management procedures. This request may beexpressed as one or more UMA messages intended for a serving UNC 224.LAN-UNC 236 receives packets containing these UMA messages and detectsthat mobile station 208 is requesting a UMA call.

When the call is detected, LAN-UNC 236 continues to monitor packetsexchanged by mobile station 208 and intercepts a unique identifierassociated with the called party. The unique identifier may include, forexample, the IMSI (international mobile subscriber identity) of thecalled party. LAN-UNC 236 may use the unique identifier to determinewhether the called party is connected to local area network 204. IfLAN-UNC 236 determines that the called party is not connected to LAN204, it may pass packets from mobile station 208 to serving UNC 224without further processing. If, however, LAN-UNC 236 determines that thecalled party is connected to local area network 204, it may performadditional processing of the call traffic. Additional call processingmay include redirecting call audio data.

In some embodiments, LAN-UNC 236 allows the call setup process toproceed normally and then redirects the audio stream. Thus, for example,LAN-UNC 236 sends the call request to serving UNC 224 where is relayedto a mobile switching center 228. Mobile switching center (MSC) 228directs serving UNC 224 to establish a connection between mobile station208 and a specified port on its A-interface. When call setup hascompleted, LAN-UNC 236 receives call audio packets from mobile station208 and transfers them to the called party within local area network204. Thus, unlike conventional systems, packets representing call audiodata are maintained within local area network 204 when both caller andcallee are connected to local area network 204. The process throughwhich LAN-UNC 236 maintains call audio packets within local area network204 is variously described hereinafter as “localizing” or“short-cutting” the call audio data. Localizing call audio is performedwhen both parties to a call are connected to the same local areanetwork.

B. Device Location Table

As UMA devices 208, 210, 240 successfully complete the discovery andregistration process, LAN-UNC 236 may add entries to a device locationtable. Entries in the device location table may include, for example,the IMSI of the fully registered UMA device and may indicate that thedevice is actively connected to local area network 204. If a UMA device208, 210, 240 disconnects from local area network 204, LAN-UNC 236 mayremove its information from the device location table. In addition,LAN-UNC 236 may periodically update information stored in the devicelocation table in response to system events and other occurrences.

FIG. 3 shows an exemplary device location table 300 maintained by aLAN-based UMA network controller according to an embodiment of thepresent invention. As shown, device location table 300 is a generalizeddata structure containing information about communication devicesconnected to a local area network. In some embodiments, entries indevice location table 300 contain, at least, a unique identifierassociated with a particular communication device connected to the localarea network. The format of the unique identifier may vary according todevice type and, in some embodiments, includes an email address, an IPaddress, or a telephone number. Additional information, such as devicetype, device location, call status, and usage statistics may also bestored in device location table 300. Although shown as a table, it willbe understood by those skilled in the relevant art that device locationtable 300 may comprise other data structures without departing fromspirit of the present invention.

When a call request is detected, LAN-UNC 236 may search a devicelocation table for an entry that matches the call recipient's uniqueidentifier. If no matching entry is found, this may indicate that thecall recipient is not connected to local area network 204 or has notbeen properly registered on the UMA network. If a matching entry isfound, however, this indicates that the call is being placed betweenregistered UMA devices and that both of the devices are connected tolocal area network 204. Thus, if both mobile stations 208, 210 areconnected to LAN 204 and both are properly registered on the UMAnetwork, entries for both devices will be included in the devicelocation table. By using information in the device location table, aLAN-UNC 236 may determine when it is appropriate to localize call audiodata. A device location table may also facilitate communication betweenUMA and non-UMA devices connected to the same local area network asdiscussed in more detail below.

C. Keep-Alive Packets

In some embodiments, LAN-UNC 236 is configured to send placeholder audiopackets to serving UNC 224 when it localizes call audio data. Forexample, LAN-UNC 236 may generate dummy RTP (Real-time TransportProtocol) packets to simulate call audio data and send them to servingUNC 224 at predetermined intervals. These dummy RTP packets ensure thata viable voice path exists between LAN-UNC 236 and serving UNC 224 andmay be used to facilitate hand-over between the UMA network and thecellular network. By way of illustration, LAN-UNC 236 may beginlocalizing audio data for a call placed between a first mobile station208 and a second mobile station 210. During the call, second mobilestation 210 may disconnect from local area network 204 and behanded-over to the cellular network. This process may occur, forexample, if second mobile station 210 leaves the coverage area ofwireless access point 212. Mobility management features in second mobilestation 210 may detect reduced signal strength on the wireless networkconnection and initiate a hand-over to the appropriate cellular basestation.

When LAN-UNC 236 detects that second mobile station 210 has requested ahand-over, it may discontinue sending placeholder audio packets andbegin sending audio packets from first mobile station 208 to serving UNC224 on the voice path. Since only first mobile station 208 remainsconnected to local area network 204, the call proceeds in the normalfashion. Audio data from first mobile station 208 is carried by internetconnection 220 to serving UNC 224. MSC 228 receives the call audio fromserving UNC 224 and sends it to the appropriate cellular base station.The cellular base station transmits the call over the air and it isreceived by second mobile station 210. On the return trip, call audiodata is received from second mobile station 210 at the base station. MSC228 directs the call to serving UNC 224 and it is then forwarded toLAN-UNC 236. LAN-UNC 236 delivers the call to first mobile station 208.In this way, call audio data is de-localized in response to thehand-over event.

D. Data

UMA devices 208, 210, 240 may also generate requests for data servicessuch as web browsing or email. In some embodiments, LAN-UNC 236 detectsthese requests and determines whether they can be fulfilled usingLAN-based resources. For example, LAN-UNC 236 may communicate withapplication server 218. If application server 218 can fulfill a dataservices request, LAN-UNC 236 may establish a connection and route datatraffic between the UMA device and application server 218 over the localarea network 204. LAN-UNC 236 may be configured to route some requestsfor data services to application server 218 over LAN 204 and to routeother requests for data services to serving UNC 224 and on to SGSN 232.This expands the set of data services available to UMA devices 208, 210,240 and permits preference-based resource selection. In an exemplaryembodiment, LAN-UNC 236 supports communication with IMS network 240 foraccessing data services.

II. Authentication

Interaction between a LAN-UNC and a UMA device typically begins with anauthentication process. As part of the authentication process, the UMAdevice provides its credentials to the core cellular network. If thecellular network accepts the credentials, a secure communication channelis formed and the authentication process is completed successfully.Thereafter, the UMA device can access voice and data services availablethrough the cellular network.

Authentication in a conventional UMA system is conducted using an IKEv2w/EAP-SIM (Internet Key Exchange) protocol and results in the formationof a single IPSec (IP Security) tunnel between a mobile station and aserving UNC. As part of the IKE process, a UNC may authenticate itselfto the mobile station using a public certificate signed by a trustedparty. The mobile station, in turn, authenticates itself to the cellularnetwork and to the UNC using credentials stored in its subscriberidentification module (SIM). The two sides negotiate encryption methodsand exchange keying material which is used to derive cryptographic keys.The cryptographic keys are then used for origin authentication and toencrypt communications for transport through the IPSec tunnel.

A LAN-UNC may participate in the authentication process in several ways.In some embodiments, the LAN-UNC is disposed as part of the IPSec tunnelconnecting the mobile station to the serving UNC. In such embodiments,the LAN-UNC functions as a seamless part of the IPSec tunnel andtransparently intercepts packets as they travel through the tunnel. Inother embodiments, the LAN-UNC may proxy a connection between the mobilestation and the serving UNC. In this arrangement, the LAN-UNC forms twoIPSec tunnels—a first IPSec tunnel within the local area network, and asecond IPSec tunnel extending over an external network—to carrycommunication between the mobile station and the serving UNC. In yetanother embodiment, the LAN-UNC may form separate IPSec tunnels for eachUMA device on the local area network, but utilize a single securechannel over the external network to carry packets for most (or all) ofthe individual UMA devices. These embodiments are described in greaterdetail below.

A. Seamless Connection

FIG. 4 is a conceptual view 400 of a LAN-UNC disposed within an IPSectunnel according to an embodiment of the present invention. In thisembodiment, the IPSec tunnel connects mobile station 208 with servingUNC 224 and is represented by arrows pointing in both directions.LAN-UNC 236 does not terminate the tunnel but instead intercepts packetsas they pass through the tunnel. In one direction, the tunnel carriespackets from mobile station 208 to serving UNC 224. As shown, LAN-UNC236 intercepts the packets before they reach serving UNC 224. In theother direction, LAN-UNC intercepts packets carried from serving UNC 224to mobile station 208. LAN-UNC 236 may decrypt and process the packetsas needed. LAN-UNC 236 may encrypt the processed packets and place themback into the tunnel for transport. Alternatively, LAN-UNC 236 may addor remove packets from the tunnel entirely. The process of intercepting,decrypting, and processing packets is transparent to both mobile station208 and serving UNC 224 and is performed in both directions.

FIG. 5 shows parts of an authentication process conducted according toan embodiment of the present invention. As shown, LAN-UNC monitors anIKE process that results in the formation of an IPSec tunnel betweenmobile station (MS) and serving UNC (S-UNC). As a part of this process,LAN-UNC confirms that mobile station MS has been properly authenticatedby the core cellular network and obtains the cryptographic keys neededto access packets exchanged over the IPSec tunnel. Arrows are shown asrepresenting exchanges between the various entities participating in theIKE process. Also, short text descriptions are attached to each arrow.It will be understood that these arrows and text descriptions areintended to broadly illustrate the authentication process and that someexchanges and exchange parameters have been omitted for clarity.

In a first exchange, MS initiates an IKE security association withS-UNC. This exchange may involve multiple packets and is represented byIKE_SA_INIT. As part of the exchange, for example, MS and S-UNC maynegotiate encryption algorithms and generate initial cryptographic keys.These keys are used to protect the IKE exchange and to encrypt data inthe resulting IPsec tunnel. In some embodiments, LAN-UNC receivesprivate keying material for use in decrypting communications between MSand S-UNC. For example, S-UNC may cooperate with LAN-UNC by providingthe shared secret used to generate Diffie-Hellman session keys.Alternatively, MS may provide the necessary keying information.

Using a combination of public and private keying material, LAN-UNCmonitors subsequent exchanges between MS and S-UNC.

As part of the IKE security association, MS may require S-UNC toauthenticate its identity. In some cases, S-UNC authenticates itsidentity by encrypting data with a public certificate that has beensigned by a trusted authority. If MS accepts these credentials, anEAP-SIM (Extensible Authentication Protocol/SIM implementation) exchangebegins through which MS is authenticated to the cellular network.

Authentication with the cellular network is based upon a cellular sharedsecret (Ki) that is known to both MS and the cellular provider. A copyof the Ki may be stored in a Home Location Registry (HLR) located withinthe core cellular network. In some embodiments, LAN-UNC also stores acopy of the Ki and uses it to monitor or participate in the exchange ofEAP-SIM messages. Mutual authentication for the IKE process is completewhen MS successfully proves its identity to the core cellular networkand this results in the formation of an IPSec tunnel between MS andS-UNC. Keying material produced as part of the IKE/EAP-SIM process isused by S-UNC to encrypt data for transport through the IPSec tunnel.

IKE_SA_INIT starts the EAP-SIM exchange. In a first part of the EAP-SIMexchange, S-UNC locates a secure (AAA) server through which it canaccess data stored within the core cellular network. AAA serverimplements a protocol such as RADIUS (Remote Authentication Dial-InService) to communicate securely with S-UNC. In some embodiments, aRADIUS client in S-UNC sends IMSI information for MS to the AAA server.This exchange is represented by an EAP Response/Identity message inwhich the IMSI is conveyed as part of an NAI (network addressidentifier). Next, AAA server generates an EAP Request/SIM-Start messageto acknowledge that the EAP-SIM process has been initiated. S-UNC sendsthe EAP Request/SIM-Start message to MS. LAN-UNC intercepts the EAPRequest/SIM-Start message before it reaches MS and prepares to monitorthe authentication process. LAN-UNC may store a copy of the interceptedmessage as it travels to MS. This copying operation may be performed forall intercepted packets without delaying transmission.

MS may respond to the EAP Request/SIM-Start message by generating an EAPResponse/SIM-Start message which includes a NONCE_MT parameter. NONCE_MTrepresents a random number chosen by MS to be used as part of theauthentication process. LAN-UNC receives the EAP Response/SIM-Startmessage and directs it to S-UNC. LAN-UNC may record the value ofNONCE_MT for later use. S-UNC relays the EAP Response/SIM-Start messageand NONCE_MT parameter to AAA server. AAA server sends NONCE_MT to thecore cellular network. In some configurations, AAA server is disposedwithin an Authentication Centre (AuC). AuC accesses information from thecore cellular network using the IMSI of MS. Using this information, AuCgenerates one or more cellular triplets with which to verify theidentity of MS.

As those of skill in the art will recognize, cellular triplets aregenerally expressed as a group comprising (RAND, SRES, K_(C)). RANDrepresents a random number generated by the AuC upon which calculationsare performed to verify a subscriber's identity. SRES is a signedresponse value produced by a proprietary GSM authentication algorithmusing the values of RAND and shared secret Ki. K_(C) is a cryptographickey derived from the Ki and RAND according to another proprietary GSMauthentication algorithm. Thus, it will be apparent that cellulartriplets can be calculated if the GSM authentication algorithms andshared secret Ki are known. In addition, possessing the full set ofcellular triplets enables keying material and authentication codes to bederived.

Using the cellular triplets, AAA server generates an EAPRequest/SIM-Challenge message that may include various parameters. Asshown, the challenge message includes RAND, MAC, and Re-Auth IDparameters. RAND represents the random number generated by the AuC andis part of the cellular triplet. MAC is a general message authenticationcode that is used to protect the challenge. Re-Auth ID may be used aspart of a subsequent re-authorization procedure. S-UNC receives the EAPRequest/SIM-Challenge message and forwards it to MS. LAN-UNC mayintercept the message and record elements of the challenge such as theRAND and MAC. LAN-UNC may use these parameters to monitor the state ofauthentication process in subsequent exchanges. In some embodiments, thecellular shared secret Ki and GSM authentication algorithms are suppliedby a cellular provider and used by LAN-UNC is to monitor theauthentication process and to access derived keying material.

As shown, LAN-UNC communicates the EAP Request/SIM-Challenge message toMS. On receipt of the EAP Request/SIM-Challenge message, MS may run theGSM authentication algorithm and calculate a copy of the messageauthentication code. If the MAC calculated by MS matches the MACreceived as a parameter of the SIM-challenge message, MS is assured thatS-UNC has access to valid cellular triplets. MS may respond to the RANDchallenge by generating a local SRES value. As shown, MS calculates amessage authentication code based upon the local SRES value and sends itto S-UNC as an EAP SIM/Response-Challenge message. LAN-UNC interceptsthe Response-Challenge message and, in some embodiments, verifies thenew MAC using its copy of the Ki. In this way, LAN-UNC can independentlyauthenticate MS and can take appropriate action if authentication is notsuccessful.

LAN-UNC forwards the EAP SIM/Response-Challenge message to S-UNC. S-UNC,in turn, forwards the message to AAA server in RADIUS. AAA serverattempts to verify the MAC calculated by MS. If the MAC is correct, AAAserver may send an EAP Success message to S-UNC. In some cases, thismessage may be accompanied by derived keying material for use incompleting the IKE negotiation between S-UNC and MS. S-UNC sends the EAPSuccess message to MS. LAN-UNC may intercept the message and verify thatMS authenticated successfully with AAA server. LAN-UNC may also recordkeying material received from S-UNC before forwarding the EAP Successmessage to MS. In some embodiments, S-UNC cooperates to provide keyingmaterial outside of the EAP-SIM process.

At this point, MS has authenticated with the cellular network and IKEmutual authentication is complete. As a last part of the IKE process, anIPSec security association is created between MS and S-UNC. The IPSecsecurity association completes tunnel formation and a registrationprocess can commence. Keys generated during the IKE process are used toencrypt packets exchanged between MS and S-UNC. By participating in theprocess, LAN-UNC has acquired all keying material necessary to encryptand decrypt tunnel traffic and has full access to packets sent betweenthe two devices.

LAN-UNC may not always have possession of the Ki value for each MSconnected to the local area network. In many cases, Ki values areclosely guarded by cellular providers and their distribution and storageoutside of the core cellular network may not be possible. In such cases,LAN-UNC may be adapted to receive cellular triplets from a serving UNCor other suitable device over the external network. Using theappropriate cellular triplet information, LAN-UNC participates fully inthe IKE/EAP-SIM process and becomes a seamless as part of the resultingIPSec tunnel.

FIG. 6 shows parts of an authentication process conducted according toanother embodiment of the present invention. In this embodiment, LAN-UNCreceives IKE private key information, monitors the IKE process, anddetects initiation of EAP-SIM authentication. AAA server receives an EAPResponse/SIM Start message and requests cellular triplets from HLR. AAAserver then delivers the cellular triplets to S-UNC. S-UNC, in turn,cooperates to deliver the cellular triplets to LAN-UNC. With possessionof the triplets, LAN-UNC monitors and participates in the authenticationprocess as previously described.

FIG. 7 shows exchanges forming part of an authentication processaccording to a further embodiment of the present invention. In thisembodiment, LAN-UNC is adapted to receive cellular triplets from amobile station. This provides additional flexibility in performing theauthentication process. For example, LAN-UNC may maintain a list oftrusted mobile stations. During the IKE process, the IMSI of a mobilestation may be compared to the list of trusted mobile stations. Mobilestations on the list may be specially configured to deliver cellulartriplets to LAN-UNC at an appropriate time during the authenticationprocess. Thus, LAN-UNC may permit a trusted mobile station to initiateauthentication while blocking untrusted mobile stations.

As shown, mobile station MS generates triplets locally in response toreceiving the EAP Request/SIM-Challenge message. In one embodiment, MScooperates to transfer its locally generated triplets to LAN-UNC. Thistransfer may occur as one or more messages exchanged between thedevices. In some embodiments, MS provides locally generated triples toLAN-UNC over a secure communication path that is maintained separatelyfrom the IKE process. Using triplets received from MS, LAN-UNC monitorsand participates in the authentication process as previously described.

B. Proxy Connection

FIG. 8 is a simplified block diagram of a LAN-UNC 828 interacting withvarious elements of a UMA communication system according to anembodiment of the present invention. Serving UNC 836 is shown asincluding a RADIUS client, an IP network controller (INC), a securitygateway (SGW), and a media gateway (MG). SGW terminates incoming tunnelsand protects the carrier network. INC provides a Gb interface to connectserving UNC 836 to SGSN 228. Similarly, MG provides an A interface toconnect serving UNC 836 to MSC 232. INC, SGW, and MG may be separatecomponents or, in some cases, their functions may be integrated in asingle unit. In addition, INC and MG may separately addressable withinthe core cellular network.

Serving UNC 836 is also shown as connected to HLR/AuC 848 by an SS7-MAP(Signaling System #7-Mobile Application Part) connection. Using theSS7-MAP connection, serving UNC 836 can access HLR/AuC and obtaincryptographic keys and other information for a particular communicationsession. An IPSec control tunnel 832 extending between serving UNC 836and LAN-UNC 828 enables the cryptographic keys and other information tobe securely transferred between devices.

In this embodiment, LAN-UNC 828 is configured to proxy a connection toserving UNC 836 on behalf of mobile stations 208, 210. As proxy, LAN-UNC828 receives incoming packets from mobile stations 208, 210 and createsnew packets for transmission to serving UNC 836. Rather thanintercepting packets as they pass through a single IPSec tunnel, twoIPSec tunnels are formed per UMA device. A first IPSec tunnel extendsfrom a mobile station to LAN-UNC 828. The first IPSec tunnel runscompletely within the local area network and is terminated at LAN-UNC828. A second IPSec tunnel extends from LAN-UNC 828 to serving UNC 836.The second IPSec tunnel runs over the external network and is terminatedat serving UNC 836.

Mobile stations 208, 210 are connected to a local area network (notshown) by wireless access point 212. IPSec tunnel 808 carries packetsfrom first mobile station 208 to LAN-UNC 828 over the local areanetwork. IPSec tunnel 812 carries first mobile station 208 packets fromLAN-UNC 828 to serving UNC 836. In like manner, IPSec tunnel 820 carriespackets from second mobile station 210 to LAN-UNC 828 and IPSec tunnel824 carries second mobile station 210 packets from LAN-UNC 828 toserving UNC 836. In a typical configuration, these tunnels are formed aspart of the process by which a UMA device authenticates with thecellular network. This process is described in greater detail withreference to the following figures.

FIG. 9 shows parts of an authentication process conducted according toan embodiment of the present invention. As shown, LAN-UNC proxies aconnection between a mobile station (MS) and a serving UNC (S-UNC) bycreating two IPSec tunnels to carry packets between the devices. In theauthentication process, LAN-UNC impersonates both sides of the exchange.Thus, LAN-UNC interacts with MS as if it was a serving UNC. Similarly,LAN-UNC interacts with S-UNC as if it was an ordinary UMA device. Insome embodiments, LAN-UNC is preconfigured with appropriateauthentication material for this purpose. For example, LAN-UNC may storeone or more public certificates for use in authenticating itself as aUMA network controller to MS.

Authentication is performed as part of an IKE process with EAP-SIM aspreviously described. As shown, a first IKE security association(IKE_SA1) is formed between MS and LAN-UNC and a second IKE securityassociation (IKE_SA2) is formed between LAN-UNC and S-UNC. The formationof the first security association is represented by dashed arrow 904 andlabeled IKE_SA1_INIT. The formation of the second security associationis represented by dashed arrow 908 and labeled IKE_SA2_INIT. The dashedarrows may signify the exchange of several messages. IKE_SA1 and IKE_SA2may or may not contain matching parameters. For example, in a typicalconfiguration, a same encryption method may be specified as part of eachsecurity association but the encryption keys may be different. LAN-UNCmay utilize pre-loaded public certificates during formation of IKE_SA1in order to authenticate itself to MS as a trusted UMA networkcontroller. Similarly, LAN-UNC may offer the IMSI of MS to S-UNC duringformation of IKE_SA2.

After the IKE security associations are formed, MS authenticates itselfthrough the EAP-SIM challenge-response mechanism previously described.In some embodiments, LAN-UNC possesses the cellular shared secret Ki. Aseparate Ki may be pre-loaded into LAN-UNC for each authorized UMAdevice. Alternatively, LAN-UNC may request the Ki from S-UNC through aseparate control channel.

Using the cellular shared secret Ki, LAN-UNC can complete the formationof both IPSec tunnels. LAN-UNC authenticates MS by verifying itsresponse to the RAND challenge. MS generates an EAPSIM/Response-Challenge message including the MAC it calculates. As shownin box 912, LAN-UNC verifies the received MAC using the cellular sharedsecret Ki. Upon successful verification of the MAC, MS is authenticatedto LAN-UNC. LAN-UNC completes authentication with the cellular networkby generating its own EAP SIM/Response-Challenge message containing themessage authentication code. LAN-UNC forwards this message to S-UNC and,as shown in box 916, it is subsequently verified by a AAA server. If AAAserver successfully verifies the MAC, is authenticated to the cellularnetwork. At this point, mutual authentication for both IKE exchanges iscomplete and two IPSec tunnels are formed. The first IPSec tunnel 920extends between MS and LAN-UNC over the local area network. The secondIPSec tunnel 924 extends between LAN-UNC and S-UNC over the externalnetwork. When first IPSec tunnel 920 and second IPSec tunnel 924 arecomplete, LAN-UNC functions as a man-in-the-middle for all packetsexchanged between MS and S-UNC.

FIG. 10 shows exchanges forming part of an authentication processaccording to an embodiment of the present invention. In this embodiment,a serving UNC (S-UNC) delivers triplets to LAN-UNC as part of theauthentication process. S-UNC includes an internal RADIUS function/AAAserver which processes the EAP negotiation and communicates directlywith HLR. In response to sending authentication data, S-UNC receivestriplets from HLR as shown by dashed arrow 1004. S-UNC then sends thetriplets to LAN-UNC. This is represented by dashed arrow 1008. Afterreceiving triplets from S-UNC, LAN-UNC completes the authenticationprocess resulting in formation of the first IPSec tunnel 920 and secondIPSec tunnel 924 as previously described.

FIG. 11 shows parts of an authentication process conducted in accordancewith an embodiment of the present invention. In this embodiment, amobile station MS delivers triplets to LAN-UNC as part of theauthentication process. For example, MS may include a UMA client adaptedto deliver triplets to LAN-UNC as represented by dashed arrow 1104.After receiving triplets from MS, LAN-UNC completes the authenticationprocess resulting in formation of the first IPSec tunnel 920 and secondIPSec tunnel 924 as previously described.

C. Tunneled Connection

FIG. 12 is a simplified block diagram of a LAN-UNC operating as part ofUMA communication system according to an embodiment of the presentinvention. In this embodiment, a plurality of UMA devices 1208 exchangepackets with LAN-UNC 1204 over the local area network. As shown, eachUMA device in the plurality of UMA devices 1208 communicates withLAN-UNC 1104 through a separate IPSec tunnel LAN-UNC 1204 receivespackets from the separate IPSec tunnels and transports them through atransport tunnel 1216 to a serving UNC 1212. Transport tunnel 1216 maybe an IPSec tunnel, a GRE (Generic Routing Encapsulation) tunnel, orother standard network transport mechanism.

In some embodiments, data from the plurality of UMA devices 1208 ismultiplexed and a stream of multiplexed packets are sent throughtransport tunnel 1216 to serving UNC 1212. Serving UNC 1212 terminatesthe tunnel, demultiplexes the packets, and directs them to theirdestinations within the core cellular network. This embodiment usesnetwork resources efficiently and reduces processing requirements. Forexample, processing overhead associated with maintaining separate IPSectunnels over the external network is eliminated. Transport tunnel 1216may be an IPSec tunnel or some other form of network transport.Additionally, with cooperation between the LAN-UNC 1204 and serving UNC1212, audio and data may be compressed, or otherwise optimized, in orderto increase bandwidth efficiency. Voice optimization schemes suitablefor this purpose are well-known to those of ordinary skill in the art.

FIG. 13 is a simplified block diagram of a LAN-UNC interacting withvarious elements of a UMA communication system according to anembodiment of the present invention. As shown, UMA phones 240, 242 areconnected to LAN-UNC 1304 by separate IPSec tunnels 1316, 1320. A singleIPSec transport tunnel 1324 connects LAN-UNC 1304 to serving UNC 1328.In this embodiment, LAN-UNC 1304 includes a RADIUS client for obtainingauthentication data from a RADIUS server 1332 located within the corecellular network. Communication between LAN-UNC 1304 and RADIUS server1332 may be carried by IPSec transport tunnel. In some embodiments,IPsec termination block 1308 includes a RADIUS Relay agent to facilitatecommunications between the LAN-UNC 1304 and RADIUS server 1332.

Serving UNC 1328 is shown as including an IPSec termination block 1308.In some configurations, IPSec termination block 1308 terminates IPSectransport tunnel 1324 and replaces the security gateway function SGW ofconventional UMA network controllers. IPSec termination block 1308decrypts packets carried by IPSec transport tunnel 1324 and transportsthe decrypted packets to their final destinations within the carriernetwork. For example, IPSec termination block may be connected to RADIUSserver, IP network controller (INC), and media gateway (MG). Usinginside addressing information from the tunneled packets, IPSectermination block 1308 directs the packets to their destinations withinthe core cellular network. In some embodiments, LAN-UNC 1304 and IPSectermination block 1308 cooperate to modify the security associations ofIPSec transport tunnel 1324. In this way, a list of addresses may bemaintained and used to control access to IPSec transport tunnel 1324.IPSec termination block 1308 may also demultiplex, decompress, andperform additional processing of optimized packets as required.

FIG. 14 shows parts of an authentication process conducted according toone embodiment of the present invention. In this embodiment, LAN-UNCincludes a RADIUS client that interacts directly with a AAA server inthe core cellular network. Using the RADIUS client, LAN-UNC completesauthentication and IPSec tunnel formation for mobile station MS. Theauthentication process includes an IKE exchange and EAP-SIM challengemechanism as previously described. As shown, the first IPSec tunnelconnecting MS to LAN-UNC over the local area network is formed.Communication between LAN-UNC and serving-UNC (not shown) is carried bya single IPSec transport tunnel as previously described.

FIG. 15 is a simplified block diagram of a LAN-UNC operating as part ofa UMA communication system according to an embodiment of the presentinvention. In this embodiment, LAN-UNC 1504 communicates with remoteRADIUS client 1508 to obtain authentication data from RADIUS Server1232. As shown, a redundant connection is provided between LAN-UNC 1504and remote RADIUS client 1508. Remote RADIUS client 1508 communicatesLAN-UNC requests to RADIUS server 1232. RADIUS server 1232 maintains aconnection to HLR/AuC 748. This arrangement permits LAN-UNC 1504 torequest and receive authentication data needed to participate in theauthentication process.

FIG. 16 shows formation of an IPSec transport tunnel according to oneembodiment of the present invention. In this embodiment, LAN-UNCcommunicates with a RADIUS client located within a serving UNC (S-UNC)and initiates an IKE/EAP-SIM process. IKE/EAP-SIM messages are exchangedas previously described. However, in this embodiment, LAN-UNC providesits own credentials as part of the challenge-response process and isauthenticated by the cellular network on this basis. The resulting IPSectransport tunnel is based upon mutual authentication between LAN-UNC andthe cellular network. This process may be performed manually or may beautomated. In an exemplary embodiment, LAN-UNC includes a USB (UniversalSerial Bus) port adapted to receive a SIM module. When a SIM module isdetected at the USB port, LAN-UNC executes an automated tunnel formationprocedure. Using the cellular shared secret (Ki) and GSM algorithmsstored on the USB-SIM module, the IPSec transported tunnel is formedwith little or no outside intervention.

FIG. 17 shows parts of an authentication process conducted according toanother embodiment of the present invention. In this embodiment, amobile station MS authenticates with the cellular network using anIKE/EAP-SIM process as previously described. Authentication isadministered by a remote RADIUS client. This arrangement can beappreciated with reference to FIG. 15. LAN-UNC interacts with the remoteRADIUS client to authenticate mobile station MS. Upon successfulauthentication, an IPSec tunnel 1704 is formed between MS and LAN-UNCover the local area network. In addition, LAN-UNC may signal S-UNC tomodify or re-program the security association of transport tunnel 1708.For example, addressing information associated with MS may be added toan access list that controls which packets are allowed to enter thetransport tunnel.

III. Discovery & Registration

A. Address Substitution

A LAN-based UMA network controller according to the present inventionmay also participate in the discovery process by which a UMA deviceacquires the address of a default UNC. FIGS. 18A and 18B show parts of adiscovery process for a mobile station MS that has not previouslyaccessed UMA service according to one embodiment of the presentinvention. In a typical configuration, MS will be supplied with thefully-qualified domain name (FQDN) of a provisioning UNC (P-UNC) when itis placed into service. In some cases, the FQDN points to a securitygateway at P-UNC (P-SGW). When UMA service is requested, mobile stationMS may attempt to contact P-SGW.

This process may begin when MS makes a DNS request including addressinginformation for P-SGW. The DNS request may be received 1804 by a DNSserver (DNS-LAN) located within the local area network. In someembodiments, DNS-LAN is configured to respond to the DNS request bysubstituting an address 1808 for a LAN-based UMA network controller(LAN-UNC). When mobile station MS receives the IP address of LAN-UNC, itmay initiate an IKE process 1812 as previously described. As shown,LAN-UNC responds 1820 by contacting P-UNC and initiating anauthentication process. For example, LAN-UNC may proxy a connectionbetween mobile station MS and P-UNC. As part of the authenticationexchange, LAN-UNC may provide P-UNC with the IMSI and LAI (location areaidentity) for mobile station MS. P-UNC may respond 1824 by providing anaddress for a default UNC (D-UNC).

In a next sequence of exchanges, mobile station MS may attempt toregister with D-UNC 1832 using the addressing information received fromP-UNC. At this point, LAN-UNC may terminate the previous connection toP-UNC and initiate a new connection 1836 with D-UNC. As shown, D-UNC mayrespond with addressing information 1840 for an appropriate serving UNC(S-UNC) based upon the location of mobile station MS. LAN-UNC relaysthis addressing information 1844 to mobile station MS. In somecircumstances, additional stages of the discovery process may berequired before locating S-UNC. In exemplary embodiments, LAN-UNCactively monitors each stage of the discovery process and replaces allUMA signaling replies containing security gateway addressing informationwith its own FQDN or IP address.

In a final round of exchanges, mobile station MS may attempt to register1848 with S-UNC using the addressing information provided by D-UNC. Ifnot already done, LAN-UNC may terminate its connection to D-UNC andinitiate a new connection 1852 to S-UNC for communicating theregistration request. If S-UNC accepts the registration request 1856,the discovery is complete and mobile station is successfully registered.At this point, serving UNC provides information to enable MS access theUMA network.

FIGS. 19A and 19B illustrate parts of a discovery process for a mobilestation MS that has previously recorded information about a default UMAnetwork controller (D-UNC) according to an embodiment of the presentinvention. As shown, mobile station MS uses stored addressinginformation to send a registration request to D-UNC without firstcontacting a provisioning UNC. Thus, MS discovers the address forserving UNC (S-UNC) after only one round of exchanges.

FIGS. 20A and 20B illustrate parts of a discovery process for a mobilestation MS that has been provisioned with the fully-qualified domainname of a LAN-based UMA network controller (LAN-UNC) according to oneembodiment of the present invention. In this case, address substitutionis not required. Mobile station MS requests and receives addressinginformation for LAN-UNC. Following an IKE exchange, LAN-UNC commenceswith discovery or registration. As shown, mobile station MS issues adiscovery request to a provisioning UNC (P-UNC). The subsequentexchanges are as previously described.

B. Forced Re-Provisioning

FIGS. 21A and 21B illustrate aspects of a discovery process according toa further embodiment of the present invention. In this embodiment, afirewall (FW) disposed within the local area network is configured toblock direct IKE exchanges with UNCs over an external network. Thisconfiguration prevents mobile station MS from bypassing LAN-UNC andcommunicating directly with either S-UNC 2104 or D-UNC 2108. Uponfailing to communicate with S-UNC and D-UNC, mobile station MS mayattempt to re-start the discovery process by requesting addressinginformation for its provisioning UNC (not shown). The address of LAN-UNCmay then be provided in response to these DNS requests. Before servicingthe request, LAN-UNC may verify whether MS is authorized to access UMAservices by checking a list of approved devices. If MS is not anapproved device, LAN-UNC may send an error message and terminate the IKEprocess. On the other hand, if MS is authorized to access UMA services,LAN-UNC may mediate a discovery exchange with P-UNC.

FIGS. 22A and 22B show an embodiment of the present invention in which aLAN-based UMA network controller (LAN-UNC) interacts with a UMA devicethat is not connected to the local area network. For example, the UMAdevice may be connected to an external local area network, such as aWiFi HotSpot. In this embodiment, a mobile station MS has stored theaddress of LAN-UNC as its default security gateway. For example, mobilestation MS may have accessed UMA service while connected to the localarea network and been forced to re-provision with the FQDN of LAN-UNC.

Mobile station MS may subsequently connect to a public network and wishto register for UMA service. As shown, mobile station MS requests DNSservice 2204 from a public DNS server (DNS-PUB) and supplies the FQDN ofLAN-UNC. DNS-PUB replies to the request 2208 with the publiclyaccessible IP address of LAN-UNC. After obtain an IP address forLAN-UNC, mobile station MS initiates an IKE exchange 2212 with LAN-UNCas previously described. At this point, LAN-UNC may assist mobilestation MS to complete the discovery and registration process. Forexample, LAN-UNC may proxy a connection between mobile station MS and aserving-UNC. In this arrangement, all data exchanged between LAN-UNC,mobile station MS, and S-UNC might be carried over the external network.Thus, audio data for calls placed to or from the externally connectedmobile station MS would not be localized.

C. Alternative Registration

FIGS. 23A and 23B show parts of a registration process conductedaccording to one embodiment of the present invention. In this scenario,a mobile station MS has accessed UMA service through a LAN-based UMAnetwork controller (LAN-UNC) and subsequently disconnected from thelocal area network. Later, mobile station MS connects to an outsidenetwork and contacts LAN-UNC to assist in the registration process.Default-UNC (D-UNC) responds to the attempted registration 2304 byindicating that service is not available. Alternatively, there may be noreply to the registration request.

In this embodiment, LAN-UNC detects the failed registration attempt 2304and proceeds to complete the registration process through apre-determined serving-UNC ( S-UNC). For example, LAN-UNC may beconfigured to supply information on behalf of MS to complete theregistration process. Thus, whereas S-UNC might deny a registrationrequest received from a mobile station that is located outside of itscoverage area, S-UNC accepts the request as properly completed byLAN-UNC. As shown, LAN-UNC provides addressing information for S-UNC2308 to mobile station MS in place of a failed (or missing) registrationresponse. Mobile station MS may then proceed to compete registration2312 through S-UNC.

FIGS. 24A and 24B show portions of a registration process conductedaccording to a further embodiment of the present invention. In thisembodiment, a mobile station MS has failed to register with anappropriate serving-UNC (S-UNC). For example, service on the externalnetwork may have been interrupted due to a network outage. In suchcases, LAN-UNC may complete the registration process locally 2404 andpermit mobile station MS to access LAN-based resources. As part of localregistration, for example, LAN-UNC may add an entry for mobile stationMS to a device location table. Thereafter, audio data for calls betweenmobile station MS and other UMA devices connected to the local areanetwork may be localized as previously described. In addition, afterlocal registration is complete, LAN-UNC may connect mobile station MS toan application data server through which it can access data services aspreviously described. Local registration may also permit mobile stationMS to interoperate with other LAN-based communication devices asdiscussed below.

D. Interoperability

FIG. 25 shows a LAN-based UMA network controller operating as part of aUMA communication system in accordance with an embodiment of the presentinvention. In this embodiment, LAN-UNC 2504 includes or utilizes a mediagateway 2506 element. Media gateway 2506 translates protocols andenables communication to flow between different types of devices. Asshown, media gateway 2506 is adapted to communicate with SIP device2508, H.323 device 2510, and TDM device 2512. TDM device 2512 isconnected to media gateway 2506 through PBX switch 2516. PBX switch 2516supports multiple TDM devices as separate extensions.

LAN-UNC 2504 enables calls between UMA devices 208, 210, 240 and non-UMAdevices 2508, 2510, 2512 to be carried over local area network 204. Thismay be accomplished with reference to a device location table. As shownin FIG. 3, device location table 300 stores information about varioustypes of communication devices connected to the local area network. Forexample, information about SIP devices 308 may include, among otherthings, a uniform resource locator (URL) for each SIP device connectedto LAN 204. Similarly, information about H.323 devices 312 may include,among other things, an IP address for each H.323 device connected to LAN204. Information about TDM devices, such as a PBX switch extension, mayalso be stored in the device location table.

LAN-UNC 2504 may check device location table 300 when a call setupprocedure is detected involving a LAN-based UMA device 208, 210, 240.Calls between two LAN-based UMA devices 208, 210, 240 may be handled bylocalizing call audio as previously described. In a similar manner,calls between UMA devices 208, 210, 240 and non-UMA device 2508, 2510,2512 may also be supported and maintained within local area network 204.In some embodiments, LAN-UNC 2504 retrieves appropriate identifyinginformation for the caller and callee from device location table 300. Ifcaller and callee are both connected to the local area network 204,media gateway 2506 connects the two devices on a the call and transcodestheir respective data flows. Audio data then travels back and forthacross the local area network. In an exemplary embodiment, a mediagateway controller or softswitch supervises this process and providescall control and signaling functionality.

When LAN-UNC 2404 completes a call between a UMA device 208, 210, 240and a non-UMA device 2508, 2510, 2512, it may or may not send callsignaling data to serving-UNC 224. In some embodiments, LAN-UNC 2504handles calls between UMA devices 208, 210, 240 and non-UMA devices2508, 2510, 2512 by signaling the MSC to alert it that the UMA devicehas entered in-call status.

Alternatively, LAN-UNC 2504 may not forward signaling data with respectto calls between UMA devices 208, 210, 240 and non-UMA devices 2508,2510, 2512 to serving-UNC 224. In this case, MSC 228 might be unawarethat a particular UMA device 208, 210, 240 had entered in-call statusand might route an incoming call to the UMA device 208, 210, 240 overthe UMA network. Depending upon configuration, LAN-UNC 2504 may re-routeincoming calls for a UMA device 208, 210, 240 that has entered in-callstatus to a local voice mail server or an alternative location for thecalled party.

In some embodiments, LAN-UNC is configured to interact with SIP/IMSNetwork element 2528. In such embodiments, when a UMA device 208, 210,240 authenticates and registers through LAN-UNC 2504, LAN-UNC 2504 maysend SIP registration and presence signaling to SIP/IMS network 2528.SIP/IMS network 2528 may record the registration and use thisinformation to send calls from the cellular network to LAN-UNC 2504.When a UMA device 208, 210, 240 originates a call, it may send a UMAcall setup to LAN-UNC 2504. In response, LAN-UNC 2504 may consult adevice location table. If the called party is connected to the localarea network, LAN-UNC 2504 may complete the call as previouslydescribed. If the called party is not connected to the local areanetwork, LAN-UNC 2504 may send a SIP INVITE message to IMS network 2528.IMS network 2528 may then complete the call by forwarding the SIP INVITEto a SIP proxy server or other SIP entity.

E. Single-Cell

In some embodiments, a LAN-based UMA network controller (LAN-UNC) inaccordance with the present invention is capable of performing acomplete set of voice and data functions for calls directed to and fromUMA devices connected to a local area network. In effect, the LAN-UNCacts as a single-cell within the cellular network and eliminates theneed for support from another UNC device.

FIG. 26A shows a LAN-based UMA network controller 2604 (LAN-UNC)according to one embodiment of the present invention. In thisembodiment, LAN-UNC 2604 provides full UMA networking support fordevices within local area network 204. Thus, LAN-UNC 2604 performs thecomplete set of call processing functions for UMA device 208, 210, 240and enables interoperability with non-UMA devices 2508, 2510 over thelocal area network.

As shown, LAN-UNC is connected to MSC 228 and SGSN 232 through anexternal media gateway 2608. The interface between LAN-UNC 2704 andexternal media gateway 2608 may be compliant with the UMTS (UniversalMobile Telecommunications System) specification for R4 networks. Thus,voice data exchanged between LAN-UNC 2704 and external media gateway2608 may remain GSM encoded unless the call destination is on the PSTN(public switched telephone network). In this embodiment, LAN-UNC 2604localizes audio data for calls between devices connected to the localarea network as previously described.

FIG. 26B shows a LAN-based UMA network controller 2612 (LAN-UNC)according to another embodiment of the present invention. In thisembodiment, LAN-UNC 2612 interfaces with a UMTS network 2608 and an IMSnetwork 2528. When LAN-UNC 2612 successfully authenticates and registersa UMA device with the core cellular network, it may also send SIPregistration and signaling data to a SIP or IMS server as previouslydescribed. In this way, LAN-UNC 2612 can cooperate with IMS network2620, or other SIP-based network, to complete calls. Audio data forcalls between devices that are connected to the local area network islocalized as previously described.

IV. Exemplary Procedures

FIG. 27 is a flow chart showing steps performed to localize call audiodata according to an embodiment of the present invention. In a firststep 2704, a call request is received from a UMA device connected to thelocal area network. The request may include one or more packetscontaining UMA messages. In a next step 2708, the UMA device isregistered as part of the UMA network. In some configurations, theLAN-based UMA controller acts as a proxy for packets exchanged betweenthe calling UMA device and a serving UNC. It may therefore participatein various ways as part of the discovery, authentication, andregistration processes. In other embodiments, the LAN-based UMAcontroller replaces the serving UNC and performs these functions withinthe local area network.

After the calling UMA device has been registered on the UMA network, theLAN-based UNC forwards appropriate signaling and call control messagesto the core cellular network 2712. The manner in which call signalingdata is sent depends upon how the LAN-based UNC is configured. Forexample, in a proxy configuration, packets containing UMA signaling andcontrol messages are sent through an internet-based tunnel to theserving UNC. The packets are then directed to a mobile switching center(MSC) through a voice port on the serving UNC. In other configurations,the LAN-based UNC may process these packets within the local areanetwork and communicate call signaling and control information directlyto an MSC server or SIP/IMS server.

In a next step 2716, the LAN-based UNC checks its device location tablefor an entry corresponding to the called party. This check is performedto determine whether both parties to the call are connected to the localarea network. If an entry corresponding to the called party is found inthe device location table, this indicates that callee is connected tothe local area network and is able to receive calls. In this case, theLAN-based UNC retrieves the callee's address information (uniqueidentifier) and prepares to complete the call. Different types ofaddressing information may be retrieved depending upon device type.

If an entry for the called party was found, the LAN-based UNC maintainsthe audio portion of the completed call within the local area network2720. Thus, the LAN-based UNC may receive a VoIP data flow from a callerUMA device and deliver it over the local area network to a callee UMAdevice. If the call is placed between different types of devices, theLAN-based UNC may translate between different communication protocols.For example, a media gateway element of the LAN-based UNC may convertcall data between supported formats. In each case, however, call audiois maintained in the local area network and does not travel over anexternal network. When the call is completed, the LAN-based UNC may takesteps to tear down the connection and to update its call statusinformation.

FIG. 28 is a flow chart showing steps performed as part of a handoverprocess according to an embodiment of the present invention. In a firststep 2804, a UMA device connected to the local area network initiates orreceives a voice call. Packets representing this activity are detectedby the LAN-UNC and a call setup process is initiated. The call setupprocess may involve various aspects of discovery, authentication, andregistration as previously described. When call setup is completed 2808,the LAN-UNC determines if both parties to the call are connected to thelocal area network 2812. If one calling party is not connected to thelocal area network, audio data is routed normally 2816 to itsdestination on the external network.

If both parties to the call are connected to the local area network, theLAN-UNC short-cuts the call audio data 2820. Packets detected asrepresenting call audio are maintained within the local area network andare not transmitted over the external network. LAN-UNC also generates“keep-alive” packets 2824 and sends them either to an internet-based UNCor a media gateway. Keep-alive packets ensure that the voice connectionis maintained while short-cutting call audio. At step 2832, a handoverprocess is initiated by a UMA device. If the call terminates beforehandover begins, a normal transition occurs to the cellular network2836.

Additional steps are performed as part of a mid-call handover. First,the LAN-UNC stops sending keep-alive audio packets over the externalnetwork 2840. Next, the audio stream from the calling party that remainsconnected the local area network is transferred either to aninternet-based UNC or a media gateway 2844. In this way, the callcontinues uninterrupted.

FIG. 29 is a flow chart showing a local call completion processaccording to an embodiment of the present invention. In a first step2904, packets representing an incoming call are detected by a LAN-basedUMA network controller (LAN-UNC). LAN-UNC determines an entrycorresponding to the call recipient is stored in a device location table2908. If call recipient information is not found in the device locationtable, the LAN-UNC routes the call normally 2912.

As a next part of the process, the LAN-UNC determines whether the callrecipient is on another call 2916. If the call recipient is on anothercall, LAN-UNC routes the incoming call to a voicemail server 2920.Alternatively, in some embodiments, LAN-UNC may re-route the incomingcall to another destination on the local area network. Next, LAN-UNCpages the call recipient 2924 and detects whether the call is answered2928. If there is no answer, LAN-UNC may direct the incoming call to avoicemail server 2932 as previously described.

If the call is answered, the LAN-UNC determines whether it can accessthe external network. In some embodiments, the LAN-UNC checks aninternet uplink 2936. If the internet uplink is not available, theLAN-UNC proceeds to complete the call using information from the devicelocation table 2940. In this case, billing information 2948 and othertransactional data are saved and may later be transmitted to a cellularprovider. If the internet uplink is available, the LAN-UNC proceeds tocomplete the call locally. In this situation, LAN-UNC completes the calllocally and does not signal the cellular core network 2944.

FIG. 30 is a flow-chart showing various steps performed as part of adiscovery and registration process according to one embodiment of thepresent invention. In a first step 3004, a mobile station MS connects tothe local area network. The next step depends upon whether MS haspreviously accessed UMA service through the local area network. If MShas not previously accessed UMA service through the local area network,it attempts to discover and register with a UMA network controller 3008located outside of the local area network. For example, MS may attemptto access the internet and contact a default or serving UMA networkcontroller.

A firewall service detects the attempted discovery and registration 3012and blocks access to the external network. At this point, MS falls backinto discovery mode 3016 and requests the IP address corresponding toits provisioning UMA network controller (P-UNC) from a DNS server on thelocal area network 3020. This request may include the fully-qualifieddomain name (FQDN) for P-UNC. At step 3024, resources on the local areanetwork respond to the DNS request from MS with the IP address of aLAN-based UMA network controller (LAN-UNC).

MS uses the address of LAN-UNC to initiate an internet key exchange(IKE) process 3028. As part of this process, MS sends its IMSI toLAN-UNC. In some embodiments, LAN-UNC restricts access to UMA services.In this case, LAN-UNC determines whether MS is authorized to access UMAservices by checking a list of approved devices 3036. If MS is not anapproved device, LAN-UNC sends an error message and terminates the IKEprocess 3032. If MS is authorized to access UMA services, LAN-UNCmediates a discovery exchange with P-UNC. As part of the discoveryexchange, MS requests the FQDN of a default UMA network controller(D-UNC) 3044. LAN-UNC modifies the response from P-UNC and replaces theD-UNC addressing information with its own FQDN on the local area network3044. MS stores the FQDN of LAN-UNC as its default UNC 3048.

In a next step 3052, MS requests a DNS lookup of its default UNC andreceives a IP address for LAN-UNC. If not already done, MS initiates anIKE process 3056 with LAN-UNC. LAN-UNC determines whether MS isauthorized to access UMA services 3060. If MS is not authorized toaccess UMA services, LAN-UNC may generate an error and terminate the IKEprocess 3088. This may occur, for example, if the an entry correspondingto the IMSI of MS is not found in a database of approved devices. If MSis authorized to access UMA services, LAN-UNC may proceed with adiscovery process to identify the appropriate default or serving UNC forits geographic area 3068.

If UMA service is available at its current location, LAN-UNC completes astandard registration process for MS 3076. On the other hand, if UMAcoverage is not available at MS's location, LAN-UNC may performdifferent actions. If LAN-UNC is configured to complete registrationthrough a predetermined UNC 3080, it may proceed with internet-basedregistration. In this case, LAN-UNC registers MS at the predeterminedUNC 3084 and the process is complete. If LAN-UNC is not configured tocomplete registration through a predetermined UNC, it may register MSlocally 3092 and provide information necessary for MS to accessLAN-based resources.

FIG. 31 is a block diagram of a LAN-based UMA network controller(LAN-UNC) according to an embodiment of the present invention. LAN-UNC3100 is shown as including, in part, a processor 3104, a memory 3108element, a communications module 3112, a cryptography module 3128, andan I/O interface 3116. In this embodiment, communications module 3112 isadapted to send and receive packets over a local area network.Communications module 3112 is further adapted to exchange data withdevices connected to an external network. In some embodiments,communications module 3112 exchanges IP data packets with a serving UNCover the external network. In other embodiments, communications module3112 may interact directly with a media gateway or IMS server.

Data packets received by communications module 3112 are transferred toprocessor 3104 by data bus 3120. Processor 3104 is configured to monitordata packet traffic received at communications module 3112. Dependingupon their source, processor 3104 may direct packets to cryptographymodule 3128 for encryption or decryption of data. Process 3104 isconfigured to detect packets that represent UMA voice calls. Whenpackets that represent a UMA call are detected, processor 3104determines whether the caller UMA device is properly registered with acellular communications network. If it is properly registered,processing continues. Otherwise, processor 3104 pauses until theregistration process has been successfully completed.

After verifying that the caller UMA device is properly registered,processor 3104 determines whether the callee UMA device is connected tothe local area network and able to receive calls on the local areanetwork. This information may be stored in memory 3108. In exemplaryembodiments, memory 3108 contains a device location table identifyingdevices that are able to communicate over the local area network.Processor 3104 may search the device location table for a uniqueidentifier associated with the callee UMA device. In some cases, theunique identifier may be an IMSI number.

If the unique identifier is found in the device location table,processor 3104 instructs media gateway 3124 to form a connection betweenthe caller and callee devices over the local area network. It thenroutes the audio portion of the call to the media gateway 3124 fordelivery to its destination via this connection. In this way, call audiois maintained completely within the local area network. If the uniqueidentifier is not found in the device location table, processor 3104 maypass call audio packets to cryptography module 3128 and then tocommunication module 3112 for transmission over the external network.I/O interface 3116 provides access to device settings and otherconfiguration parameters.

While the present invention has been described in terms of specificembodiments, it should be apparent to those skilled in the art that thescope of the present invention is not limited to these specificembodiments. The specification and drawings are, accordingly, to beregarded in illustrative rather than a restrictive sense. Persons ofordinary skill in the are will recognize that additions, subtractions,substitutions, and other modifications may be made without departingfrom the broader spirit and scope of the invention as set forth in theclaims.

What is claimed is:
 1. A method comprising: receiving, at a firstdevice, from a second device, first keying information that the seconddevice uses at least to encrypt packets destined for a third device;receiving, at the first device, from the third device, second keyinginformation that the third device uses at least to encrypt packetsdestined for the second device; intercepting a first encrypted packet atthe first device; decrypting the first encrypted packet at the firstdevice using the first keying information or the second keyinginformation; processing, at the first device, data resulting from thedecrypting; encrypting, at the first device, using the first keyinginformation or the second keying information, data resulting from theprocessing; sending, from the first device, toward a destinationspecified for the first encrypted packet, a second packet containingdata resulting from the encrypting; intercepting, at the first device,an Extensible Authentication Protocol (EAP) response message that thethird device sent toward the second device; storing, at the firstdevice, a value of a parameter that is indicated in the EAP responsemessage; and forwarding the EAP response message from the first deviceto the second device.
 2. The method of claim 1, further comprising:sending, from the first device to the second device, a first request forthe first keying information; sending, from the first device to thethird device, a second request for the second keying information;wherein the first keying information is received at the first device inresponse to the first request; and wherein the second keying informationis received at the first device in response to the second request. 3.The method of claim 1, wherein the first device is an Unlicensed MobileAccess (UMA) network controller that resides in a local area network inwhich the second device is contained but in which the third device isnot contained.
 4. The method of claim 1, wherein receiving the firstkeying information comprises receiving the first keying information atthe first device via the Internet from another device, said anotherdevice interfacing to both (a) the Internet and (b) a cellular network;and wherein receiving the second keying information comprises receivingthe second keying information at the first device via a local areanetwork excluding the Internet.
 5. The method of claim 1, furthercomprising: sending, from the first device to another device, saidanother device interfacing to both (a) the Internet and (b) a cellularnetwork, authentication credentials of the first device.
 6. A networkdevice comprising: means for receiving, from a second device, firstkeying information that the second device uses at least to encryptpackets destined for a third device; means for receiving, from the thirddevice, second keying information that the third device uses at least toencrypt packets destined for the second device; means for intercepting afirst encrypted packet; means for decrypting the first encrypted packetusing the first keying information or the second keying information;means for processing data resulting from the decrypting; means forencrypting, using the first keying information or the second keyinginformation, data resulting from the processing; means for sending,toward a destination specified for the first encrypted packet, a secondpacket containing data resulting from the encrypting; means forintercepting an Extensible Authentication Protocol (EAP) responsemessage that the third device sent toward the second device; means forstoring a value of a parameter that is indicated in the EAP responsemessage; and means for forwarding the EAP response message to the seconddevice.
 7. The network device of claim 6, further comprising: means forsending, to the second device, a first request for the first keyinginformation; means for sending, the third device, a second request forthe second keying information; wherein the means for receiving the firstkeying information are means for receiving the first keying informationin response to the first request; and wherein the means for receivingthe second keying information are means for receiving the second keyinginformation in response to the second request.
 8. The network device ofclaim 6, wherein the network device is an Unlicensed Mobile Access (UMA)network controller that resides in a local area network in which thesecond device is contained but in which the third device is notcontained.
 9. The network device of claim 6, wherein the means forreceiving the first keying information comprise means for receiving thefirst keying information via the Internet from another device, saidanother device interfacing to both (a) the Internet and (b) a cellularnetwork; and wherein the means for receiving the second keyinginformation comprise means for receiving the second keying informationvia a local area network excluding the Internet.
 10. The network deviceof claim 6, further comprising: means for sending, to another device,said another device interfacing to both (a) the Internet and (b) acellular network, authentication credentials of the network device. 11.A non-transitory computer-readable medium storing instructions which,when executed by one or more processors, cause the one or moreprocessors to perform steps comprising: receiving, at a first device,from a second device, first keying information that the second deviceuses at least to encrypt packets destined for a third device; receiving,at the first device, from the third device, second keying informationthat the third device uses at least to encrypt packets destined for thesecond device; intercepting a first encrypted packet at the firstdevice; decrypting the first encrypted packet at the first device usingthe first keying information or the second keying information;processing, at the first device, data resulting from the decrypting;encrypting, at the first device, using the first keying information orthe second keying information, data resulting from the processing;sending, from the first device, toward a destination specified for thefirst encrypted packet, a second packet containing data resulting fromthe encrypting; intercepting, at the first device, an ExtensibleAuthentication Protocol (EAP) response message that the third devicesent toward the second device; storing, at the first device, a value ofa parameter that is indicated in the EAP response message; andforwarding the EAP response message from the first device to the seconddevice.
 12. The non-transitory computer-readable medium of claim 11,wherein the steps further comprise: sending, from the first device tothe second device, a first request for the first keying information;sending, from the first device to the third device, a second request forthe second keying information; wherein the first keying information isreceived at the first device in response to the first request; andwherein the second keying information is received at the first device inresponse to the second request.
 13. The non-transitory computer-readablemedium of claim 11, wherein the first device is an Unlicensed MobileAccess (UMA) network controller that resides in a local area network inwhich the second device is contained but in which the third device isnot contained.
 14. The non-transitory computer-readable medium of claim11, wherein receiving the first keying information comprises receivingthe first keying information at the first device via the Internet fromanother device, said another device interfacing to both (a) the Internetand (b) a cellular network; and wherein receiving the second keyinginformation comprises receiving the second keying information at thefirst device via a local area network excluding the Internet.
 15. Thenon-transitory computer-readable medium of claim 11, wherein the stepsfurther comprise: sending, from the first device to another device, saidanother device interfacing to both (a) the Internet and (b) a cellularnetwork, authentication credentials of the first device.